分层
约束
CI
确定性
第二道护栏
架构约束 (｀・ω・´)
Architecture Constraints
(ﾉ◕ヮ◕)ﾉ
(´-ω-`)
Harness 体系中最核心的一环
用确定性规则取代模糊指令
(｡♥‿♥｡)
(｡♥‿♥｡)
(・o・)
严格的分层架构 (｀・ω・´)
OpenAI 团队建立的六层依赖规则
Types
Config
Repo
Service
Runtime
UI
每层只能依赖下方，禁止反向依赖
(；一_一)
Types Config Repo Service Runtime UI 禁止反向 ✗
(｡♥‿♥｡)
(╯°□°）╯
依赖方向规则 (・・ ) ?
单向依赖 = 可维护的架构
允许
UI 层
Service 层
Types 层
VS
禁止
Types 层
Service 层
UI 层
上层引用下层 ✓ 安全 · 下层引用上层 ✗ 危险 (；´Д｀)
(｀・ω・´)
(｡•́︿•̀｡)
(｡♥‿♥｡)
如何执行这些规则？ (・・ ) ?
不是靠 Prompt "请遵守"，而是靠机械执行

Prompt 指令

"请遵守分层架构，
不要反向依赖"

不可靠
遵守率 ~60%
→

Linter + CI 检查

确定性的自动化检测
违反即 构建失败

机械执行
遵守率 100%
约束 比 指令 更有效 (｡♥‿♥｡)
(ﾉ◕ヮ◕)ﾉ
(╯°□°）╯
(｡♥‿♥｡)
CI 自动拦截流程 (；一_一)
Agent 违规 → CI 挂掉 → 没得商量
Agent
提交代码
Linter
架构检查
结构化
测试
通过 /
拦截
违反规则 → CI 直接挂掉
报错含修复指引
报错信息嵌入 修复指引，告诉 Agent 怎么改 (｀・ω・´)
(ﾉ◕ヮ◕)ﾉ
(｀・ω・´)
(｡♥‿♥｡)
行业共识 (｡♥‿♥｡)
Cursor 团队得出完全一致的结论
"约束比指令更有效"
Cursor · "Self-Driving Codebases" 专项研究
反直觉洞察
给 AI 的 可选择范围越小、 执行边界越明确， AI 产出效率和准确率 反而越高
选择范围
大 → 低效
约束收窄
中
精准执行
小 → 高效
(｡♥‿♥｡)
(ﾉ◕ヮ◕)ﾉ
(；´Д｀)
(｡♥‿♥｡)
没有约束 = 浪费 Token (；一_一)
自由度越高，AI 试错成本越大
无架构约束
A B C D ✓
尝试方案 A
尝试方案 B
尝试方案 C
尝试方案 D
最终方案
大量 Token 浪费在
错误的、不可行的方案
VS
有架构约束
直达 ✓
直达正确方案
约束收窄选择范围
高效 · 精准 · 零浪费
选择越少 → 效率越高 → 产出越准 (｡♥‿♥｡)
(ﾉ◕ヮ◕)ﾉ*:･ﾟ✧
(´-ω-`)